Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/mint/l_1199/901

Internet Message Format | 1994-08-27 | 1.8 KB

Date: Wed, 19 Jan 1994 18:00:17 -0500
From: "Nicholas S Castellano" <[e-mail]>
To: [e-mail]
        [e-mail]
In-Reply-To: Stephen Henson's message of Wed, 19 Jan 94 15:30:33 MST <[e-mail]>
Subject: dreaddir/fxattr

>I'm still not sure about this. The delay of readdir/stat is caused by the
>multiple file lookups (e.g. several directory searches if it's a full path).
>Things which don't use the new syscall wont win. Also is it intended that the
>new library would use this syscall to reduce the work in certain situations
>(e.g. automatically with readdir).
>    Since this involves messing with the kernel, why not use a cookie
>cache which is then backwards compatible and speeds up *all* multiple
>operations on the same file (the lib is full of these) instead of just
>optimising the readdir/xattr case.
>    I could do this with an LRU cache in Minixfs lookup/readdir but it's
>best in the kernel to speed up all filesystems and to have path as opposed to
>directory dependency.

I agree that this is the best solution.  If we implement a new system
call we will still need to retain backwards compatibility in the
library (try new readdir call, if it is not available then use
readdir/getxattr) which will only make the syscall overhead greater in
many instances and complicates programming for those using the OS
interface directly without an intervening library interface.  Adding a
write-through directory cache in the kernel solves the original
problem without introducing new ones.

Cheers,
entropy

--
entropy -- it's not just a good idea, it's the second law.
Personal mail:      [e-mail]
MiNT library mail:  [e-mail]
"what do you have against octal?" -jrb